Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

grpc: ensure transports are closed when the channel enters IDLE #6620

Merged
merged 2 commits into from
Sep 12, 2023

Conversation

easwars
Copy link
Contributor

@easwars easwars commented Sep 12, 2023

Prior to channel idleness, sub-channels would be closed either because:

  • the LB policy shuts it down (or the LB policy is being switched)
    • in this case, the underlying transport is gracefully closed
  • the channel is being shutdown
    • in this case, cc.ctx is canceled
    • this context is passed to the transport, and leads to the transport shutting down

In the case of the channel moving to IDLE though, we were calling ac.tearDown, but this was not actually closing the transport because the passed in error was not errConnDrain.

With this PR, we will always close the underlying transport from ac.tearDown, either gracefully or forcefully.

RELEASE NOTES:

  • grpc: fix a bug where transports were not being closed upon channel entering IDLE

@easwars easwars requested a review from dfawley September 12, 2023 00:15
@easwars easwars added this to the 1.59 Release milestone Sep 12, 2023
clientconn.go Outdated
Comment on lines 1693 to 1697
// We have to unlock and re-lock here because GracefulClose calls
// onClose, which requires locking ac.mu.
ac.mu.Unlock()
curTr.GracefulClose()
ac.mu.Lock()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updateAddrs does the same kind of thing via a defer instead. Should we do that here to avoid giving up the lock and then taking it again? (Also we can remove the local variable curTr if we do this.)

Or, maybe just move this stuff to the very end of the function so we don't need to re-take the lock?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving to the end was simpler and felt cleaner as well. Done.

@easwars easwars assigned easwars and unassigned dfawley Sep 12, 2023
@easwars easwars merged commit 2d1bb21 into grpc:master Sep 12, 2023
1 check passed
@easwars easwars deleted the going_idle_should_close_all_transports branch September 12, 2023 20:53
easwars added a commit to easwars/grpc-go that referenced this pull request Sep 13, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants